Using M.E.T.A.

M.E.T.A. Modes

The M.E.T.A. plugin can operate in different modes. Currently it supports the following modes:

  • normal - Your application is developed outside the container tree. It must be deployed to the container by running the turbine:deploy goal.
  • inplace - The source code and the class files are kept together. Your web container will access the files in the development location and no explicit deployment to the container is necessary. This mode is similar to developing with the deprecated Turbine Development Kit.
Modes are discussed on the Modes page.

Intended Development Cycles

The goals of the M.E.T.A. plugin interact with many other goals from maven to create your build environment. As the function of some is not really intuitive, this is how the plugin is intended to be used:

Development cycle for java code
===============================

           [development start]
                   |
                   V
               maven turbine:setup - generate skeleton
                   |
                   V
+----->  [application development]
|                  |
|                  V
^              maven java:compile  - compile code
|                  |
|                  V
+-<-- yes <--- Errors / Test failures?
|                  |
^                  |  no
|                  V
|        optional: maven turbine:deploy - deploy to container
|           (not needed in "inplace" mode)
|                  |
|                  V
^          [In-container testing]
|                  |
|                  V
+-<-- yes <--- Errors?
|                  |
^                  |  no
|                  V
+-<-- no <---- Ready to ship?
                   |
                   | yes
                   V
               maven turbine:war - bind a war file
                   |
                   V
               Ship application


Development cycle for SQL code
==============================

            [development start]
                    |
                    V
                maven turbine:setup - generate skeleton
                    |
                    V
                maven torque:create-db - generate DB
                    |
                    V
 +----->  [application development]
 |                  |
 |                  V
 ^              maven turbine:sql - generate SQL code
 |                  |
 |                  V
 ^              maven torque:insert-sql - put SQL in DB
 |                  |
 |                  V
 +-<-- yes <--- Errors?
 |                  |
 ^                  |  no
 |                  V
 +-<-- no <---- Ready to ship?
                    |
                    | yes
                    V
    Ship files from target/sql directory

Preparing a new M.E.T.A. application

Ad hoc setup

If you have tried out the "helloworld" example from the Getting Started page, then you already know that setting up a new Turbine-based application is just a single maven command away. We will refer to this as "ad hoc" setup, because you do not need to prepare anything before running the turbine:setup goal.

Ad hoc setup is best used if you plan on doing lots of customization work to your properties anyway or if you just need a quick skeleton to test out something or jot down a few classes. You simply provide the application name on the maven command line and M.E.T.A. sets up the rest for you using the plugin defaults.

maven -Dturbine.app.name=<application name> turbine:setup

Note: In the subdirectory which contains your application skeleton, there will be a M.E.T.A. properties file, called setup.properties. This is auto-generated by the plugin to make your setup reproducible.

Custom setup

Sometimes, ad hoc simply will not cut the cake. Then you need to prepare a properties file for the M.E.T.A. plugin called setup.properties. It must be placed in the directory where you will run the turbine:setup goal. This properties file allows you to customize the layout of the new application.

In the application skeleton is a new setup.properties file created, which can be used to rebuild it by deleting all but this file from the directory tree and re-run turbine:setup.

You can change the name of the properties file with the turbine.setup.properties property: 

maven -Dturbine.setup.properties=helloworld.properties turbine:setup

OM Layers

Turbine supports the retrieval of information from databases through various OM layers. The most popular is Torque and Turbine itself uses Torque for the Security Service and the Scheduler Service. With the M.E.T.A. plugin, different OM layers can be configured. The default is to use Torque. The OM layer is configured by setting the turbine.app.om.layer property. Currently supported settings are:

  • torque - Configure Torque
  • none - don't use an OM layer

Demo pages

In the "helloworld" example from the Getting Started page, you have seen that a newly generated turbine application already contains a few files which allow to check the correct setup. If you don't want M.E.T.A. to put these files into the skeleton, you can set the turbine.app.setup.demo property to false: 

maven -Dturbine.app.setup.demo=false turbine:setup

Deploying your application with M.E.T.A.

Application development happens in cycles of programming, compile and deploy. If you use an external web container, you deploy your compiled application into its webapp directory. If you have a local web container that you can customize, you might want to develop directly in the webapp directory and skip the deployment.

Deployment to a web container

All your application code and Turbine support files are copied into a web container which is outside your development tree. You must configure the appserver plugin (which also gives you the power to start and stop your container from maven. See the appserver plugin documentation for more information) and its configuration is then used by M.E.T.A. The required appserver properties are listed on the Properties Page.

Inplace Development

Inplace development allows you to work directly on the files that are used by your web container. Your application code and the Turbine support files are located in a directory which is accessed by the web container.